GitHub Actions runners support x86-64-v3 (AVX2) but NOT x86-64-v4
(AVX-512). Unconditionally setting target-cpu=x86-64-v4 would break CI;
unconditionally leaving the default would mean the ndarray polyfill
never picks its AVX-512 type path even on capable hardware (the
ndarray_simd_smoke example proved this is observable: avx512f=true at
runtime but PREFERRED_F32_LANES=8 at compile time).

This template provides both profiles, opt-in:

  cargo build            → x86-64-v3 (AVX2 baseline, CI-safe)
  cargo build-avx512     → x86-64-v4 (AVX-512, 16-lane F32x16)
  cargo run-avx512       → ditto
  cargo test-avx512      → ditto
  cargo check-avx512     → ditto

Follows the existing Bevy convention of providing .cargo/config_*.toml
template files that users copy into the gitignored .cargo/config.toml.

Companion to AdaWorldAPI/ndarray PR bevyengine#142 (VBMI gate + Inf clamp + NaN
preservation in simd_exp_f32).

… SIMD

Produced by the 12-agent CCA2A round-2 fleet (see ndarray's
.claude/board/AGENT_LOG.md for full agent breakdown). Delivers the
"Bevy works on SIMD" goal: a real Bevy plugin that uses ndarray's
crate::simd polyfill end-to-end for graph rendering, plus a CI workflow,
headless integration tests, a shared palette LUT, and usage docs.

Files added:
- examples/ndarray_graph_plugin.rs (~270 lines) — NdarrayGraphPlugin
  with GraphRenderer Resource, startup seeder (64 nodes in circle layout,
  80 ring + cross edges), tick_renderer + render_to_framebuffer Update
  systems. Uses crate::simd::F32x16::mul_add via Renderer::tick →
  integrate_simd, and compose_neo4j (Pumpkin-derived rasterizer) into a
  long-lived 512x512 Framebuffer that gets palette-expanded to RGBA8
  and blitted into a Bevy Image displayed as a Sprite.
- examples/ndarray_graph_palette.rs — shared PALETTE_LUT [16 x RGBA8]
  + blit_u8_palette_to_rgba helper, both imported by the plugin via
  #[path = "ndarray_graph_palette.rs"] mod palette.
- examples/ndarray_graph_plugin_tests.rs — 5 headless integration tests
  (resource init, startup seed, F32x16::mul_add position advance,
  compose_neo4j pixel emission, simd_caps runtime detect). Runs as
  cargo run --example ndarray_graph_plugin_tests; all pass.
- examples/README_NDARRAY_PLUGIN.md — usage doc (build, run, what it
  shows, architecture ASCII diagram, compile-time vs runtime tier
  explanation, companion files).
- .github/workflows/ndarray-smoke.yml — GitHub Actions x86-64-v3
  baseline build (CI runners don't have AVX-512); installs Bevy system
  deps (libwayland-dev / libasound2-dev / libudev-dev); clones sibling
  ndarray via the same branch name with master fallback; cargo check
  on ndarray_simd_smoke + ndarray_graph_plugin.

Cargo.toml: two [[example]] entries (ndarray_graph_plugin,
ndarray_graph_plugin_tests).

Verified (Sapphire Rapids, x86-64-v3 build):
  cargo check --example ndarray_graph_plugin: clean
  cargo check --example ndarray_graph_plugin_tests: clean
  cargo check --example ndarray_simd_smoke: clean (regression-safe)
  cargo run --release --example ndarray_graph_plugin_tests:
    [test 1] PASS: GraphRenderer resource present, tick_count=0
    [test 2] PASS: front.len=2 edges.len=1
    [test 3] PASS: position[0] 10.0 -> 10.016666 (= 1.0 * DT_60 + 10.0,
                   confirms F32x16::mul_add polyfill ran inside Bevy)
    [test 4] PASS: compose_neo4j emitted 106 non-zero pixels
    [test 5] simd_caps: avx512f=true avx2=true fma=true; lanes=8
    [test 5] PASS: x86_64 has avx512f or avx2

Notable: the [test 5] line surfaces the compile-time vs runtime mismatch
(lanes=8 because CI-baseline cargo build, but CPU has avx512f=true).
cargo run-avx512 from .cargo/config_ndarray_simd.toml (already on this
branch) lifts that to lanes=16.

Architecture note for GPU-less hosts (Railway / HuggingFace Spaces /
Cloudflare / serverless): this plugin is a CPU-only path. The
Pumpkin-derived framebuffer was designed for the no-GPU case — palette
indices on CPU, 4 bpp wire format via Framebuffer::pack(). The audit
sub-fleet confirmed bevy_pbr / atmosphere / skinning paths are
GPU-offloaded on hosts with GPUs, but this plugin remains entirely
SIMD-CPU and works identically without a GPU.